home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 3.1 KB | 62 lines | [TEXT/GEOL] |
- Item 7806927 18-Feb-91 04:59PST
-
- From: SPA0137 Objectsoft SA, Spain,IDV
-
- To: S.FRIEDRICH Friedrich, Steve
- MACAPP.TECH$ MacApp Technical
-
- ------------------------------------------------------------------------------
-
- Sub: MacApp and C++
-
- Dear MacApp.Tech$ers,
-
- I am responding to a weeks worth of MacApp.Tech$ that I just read. If I don't
- mention you by name, you're free to feel singled out anyway.
-
- Steve Friedrich and the MacApp team, despite all of the benefits of MacApp, it
- has not really been a stable platform on which to develop. Simply recall the
- conversion from 1.1 to 2.0 which some out there are still doing. Or remember
- the number of bugs in the so-called 2.0 final release. Now a conversion to C++
- does not strike me as a step towards stability. Witness the volume of links
- complaining of bugs in CFront. The new architecture sounds fantastic, but why
- the language change? And why a change to another impure object-oriented
- language? Can we expect another 200-300 global variables, and functions in
- MacApp 3.0?
-
- OK, So Apple system software is written using C++. Do you just want to jump on
- the bandwagon, or are you saying that MacApp is system software? I personally
- don't see the future of object oriented languages as being anything like C++.
- While it may be a suitable tool for writing some system software, is it really
- the language for an application program? When people said MacApp was on the
- forefront it was in large part because it was written in Object Pascal. Now
- Object Pascal may not be a hip language these days, but C++? How about an
- Eiffel compiler instead? And if you're making a marketing decision, based on
- the popularity of C++, why don't you go to work with MS-DOS computers where
- most of the market is?
-
- Furthermore, if anyone's planning to make MacApp system software and restrict
- the source code, forget it. I haven't used ANY application class library which
- didn't provide source code. And I have used a few. Software ICs may be
- possible, but I haven't seen a class library yet where you didn't need to
- browse the code. And don't mention tools that show me all the relationships.
- The relationships that I want to know are what methods, to whom and when, but
- not at runtime. I want to browse them in any order. And sometimes I want to see
- the code in between, too.
-
- Finally, what about future architectural changes? Can I assume that MacApp will
- start taking advantage of C++ features? What's really going to happen to the
- code? It seems to me, browsing my MacApp 2.0.1 code, that there is quite a bit
- that could be cleaned up without a new language to do it in. In fact, the
- current MacApp goes a long way towards making Object Pascal unreadable. As far
- as maintaining two versions goes, forget it. You guys have enough trouble
- maintaining one version.
-
- Despite these ravings I will probably continue to use MacApp for Macintosh
- software projects. But I will be keeping a look out for other options. Common
- Lisp is beginning to look attractive.
-
- Barry Wilson
-
-
-